Conversation
8de2fdb0
force-pushed
the
feat/add-base-path
branch
from
d26074e to
5fea08b
Compare
- add docker build arg to set base path frontend is served under - set vite.config.ts base value based on docker build arg - update http variant request function to inject base path during calls to /api and /images - update how static assets are loaded from public folder to inject base path during vite build To use a base path build the docker image with --build-arg BASE_PATH=/hub/. All assets and api calls from the frontend will use that base path as prefix. The backend service is not using the base path, when using a proxy the base path has to be stripped.
8de2fdb0
force-pushed
the
feat/add-base-path
branch
from
5fea08b to
937c9bb
Compare
| const BASE_URL = import.meta.env.BASE_URL; | ||
| const PREFIXES = ["/api", "/images"]; | ||
|
|
||
| function startsWithPrefix(path: string, prefixes: string[]): boolean { |
There was a problem hiding this comment.
I don't think the changes in this file should be needed - requests always go to /api (this is a special request function to abstract the differences between HTTP and Wails APIs)
There was a problem hiding this comment.
Can we just do:
const BASE_URL = import.meta.env.BASE_URL || "";
args[0] = BASE_URL + args[0];
There was a problem hiding this comment.
I don't think the changes in this file should be needed - requests always go to /api (this is a special request function to abstract the differences between HTTP and Wails APIs)
Running vite build will inject the import.meta.env.BASE_URL to all resources loaded from the server, but not into the API requests, there is probably a better way to have vite modify the API urls from where they are used, but injecting it here seemed simpler then refactoring all the individual api hooks.
I only added it to the platform_specific/http variant since that feature won't make any sense with wails.
Can we just do:
const BASE_URL = import.meta.env.BASE_URL || "";
args[0] = BASE_URL + args[0];
The const import.meta.env.BASE_URL is injected from vite during build, see https://vite.dev/guide/build.html#public-base-path.
Looking at the docs for the specific vite config option it is default set to "/", my changes also added that value in the config in case the env variable BASE_PATH is unset. So it must be always "/" at that point.
About the path concatenation, yes I think so, but it would need to be some kind of path.join so /base_url/ + /api will result in /base_url/api. The slice[1] kind of expects the first char to be / and removes it and since only parameters starting with /api and /images are matched that will always be true. But that will fail in case BASE_URL is /hub.
Best is probably to add a small joinPath function.
There was a problem hiding this comment.
I simplified this in 8de2fdb0#1 and it works from my testing with caddy. Please let me know if that works for you.
One thing to note is you will need to update to use /hub rather than /hub/ for the BASE_PATH.
| # Set the base path for the frontend build | ||
| # This can be overridden at build time with --build-arg BASE_PATH=<url> | ||
| # Allows to build a frontend that can be served from a subpath, e.g. /hub/ | ||
| ARG BASE_PATH="/" |
There was a problem hiding this comment.
there is BASE_PATH and BASE_URL, we only need one, right?
There was a problem hiding this comment.
Currently BASE_URL is an already declared property used by the hub go app.
Also note there is a FRONTEND_URL used by the go app too.
There was a problem hiding this comment.
So BASE_URL is a vite specific, I think they call it URL since they allow to set the whole URL in cases resources come from a specific server (CDN for example). This feature is focused on allowing to server the frontend behind a proxy using sub path. That case is usually named base_path and I wanted to keep the top level variable reflecting that specific use case. URL would suggest to allow to change the whole URL.
I could't see a specific group set up for the /api path in the echo framework boilerplate, and a quick search seems to suggest FRONTEND_URL and BASE_PATH is used when connecting the alby account with the local hub instance ( from default https://getalby.com/).
Yes that has a potential for creating confusion. Maybe the BASE_PATH should be called VITE_FRONTEND_BASE_PATH.
Since you have a better understanding of the already existing variables, do you have any suggestion that helps differentiate ?
And I would really not focus on BASE_URL since it is a vite internal and is a constant injected into the build artefact. Runtime env variables won't reflect on that, it is just build time relevant.
There was a problem hiding this comment.
Thanks for the details, after looking into it I understand this is how vite works. And the FRONTEND_URL we have is somewhat different and only applies to Alby Cloud. So that one can probably be ignored for now.
I made some changes in this PR - could you review?
|
Hi @8de2fdb0 thanks for the PR. Could you provide a caddy or nginx config or similar that I could use for testing? |
Here is a traefik setup, that will make the hub available under http://localhost/hub/. services:
traefik:
image: traefik:v3.4.1
container_name: traefik2
command:
- --api.dashboard=true
- --api.insecure=true # WARNING: Do not use in production without proper security measures
- --providers.docker=true
- --providers.docker.exposedbydefault=false
- --entrypoints.web.address=:80
- --log.level=DEBUG # Good for debugging, adjust for production
ports:
- "80:80"
- "8080:8080" # Traefik dashboard http://localhost:8080/dashboard/
volumes:
- /var/run/docker.sock:/var/run/docker.sock:ro
networks:
- web
# serve albyhub under http://localhost/hub/
my-service:
image: localhost/getalby_hub:latest
container_name: getalby_hub
labels:
- "traefik.enable=true"
- "traefik.http.routers.my-service.rule=Host(`localhost`) && PathPrefix(`/hub`)"
- "traefik.http.routers.my-service.entrypoints=web"
- "traefik.http.services.my-service.loadbalancer.server.port=8080"
- "traefik.http.middlewares.my-service-stripprefix.stripprefix.prefixes=/hub"
networks:
- web
networks:
web: |
|
Closing in favor of #1439 |
2 participants
Small MR adding the ability to serve the hub behind a proxy.
To use a base path build the docker image with --build-arg BASE_PATH=/hub/. All assets and api calls from the frontend will use that base path as prefix.
The backend service is not using the base path, when using a proxy the base path has to be stripped.
#1025
Let me know what you think.